this works with op_mul, which is vectorized-friendly, but doesn't work
when we roll out to pattern.h because those ops will not work with
Vectorized yet. See TODO in elementwise_util.h

ghstack-source-id: 30d2311
ghstack-comment-id: 2738665976
Pull Request resolved: #9432

[ghstack-poisoned]

[ghstack-poisoned]

[ghstack-poisoned]

[ghstack-poisoned]

Set of math functions that work on both scalars and at::vec::Vectorized,
to be used in #9432.

Make sure we test the optimized versions of portable kernels even if
they are shadowed by optimized implementations. Intended to support
#9432.

This reverts commit 4c35fe0.

…nels test (#11205)", and "Add vectorization in elementwise_util (#9432)"

Stack was reverted due to internal CI failures. Reapplying as an exported internal diff so that we make sure to catch any more of those.

New fixes:
- straightforward op_sub build fixes
- s/EXPECT_EQ/EXPECT_FLOAT_EQ/ in vectorized_math_test
- define ET_USE_PYTORCH_HEADERS to detect whether exceptions are
  enabled, and use `#if` instead of `#ifdef` to check the macro so
  that we don't use PyTorch headers if exceptions are
  disabled. (otherwise, we might have problems with e.g. TORCH_CHECK)

Original summary for #11204:
Set of math functions that work on both scalars and at::vec::Vectorized,
to be used in #9432.

Original summary for #11205:
Make sure we test the optimized versions of portable kernels even if
they are shadowed by optimized implementations. Intended to support
#9432.

Original summary for #9432:

This is a first cut at #9241 . In this PR I've vectorized a small
initial set of ops: atan2, clamp, fmod_Scalar, maximum, minimum, mul,
pow, and sigmoid. In addition, the following ops should have gotten
vectorized automatically because they already used generic lambdas: add,
div, rsub, sub. I've left covering ops that use the `unary_ufunc_*`
utilities in
[pattern.h](https://github.com/pytorch/executorch/blob/main/kernels/portable/cpu/pattern/pattern.h)
for a follow-up push, because pattern.h and elementwise_util need some
work before we can migrate pattern.h's utilities to be backed by
elementwise_util.

This PR adds an interesting testing problem: in theory, *all* operators
might need test cases long enough to tickle vectorization, because we
might accidentally vectorize ops unexpectedly and break their lambdas
due to anticipated differences in semantics. I address this issue by
using Vectorized for the scalar prologue/epilogue in debug mode (we run
tests in both debug and release) so that we can detect broken lambdas. I
additionally intentionally introduced a bug in the vectorized path in
elementwise_util and manually verified that we saw test failures for
each vectorized op called out above.

Differential Revision: [D76467389](https://our.internmc.facebook.com/intern/diff/D76467389/)

[ghstack-poisoned]

…nels test (#11205)", and "Add vectorization in elementwise_util (#9432)"

Stack was reverted due to internal CI failures. Reapplying as an exported internal diff so that we make sure to catch any more of those.

New fixes:
- straightforward op_sub build fixes
- s/EXPECT_EQ/EXPECT_FLOAT_EQ/ in vectorized_math_test
- define ET_USE_PYTORCH_HEADERS to detect whether exceptions are
  enabled, and use `#if` instead of `#ifdef` to check the macro so
  that we don't use PyTorch headers if exceptions are
  disabled. (otherwise, we might have problems with e.g. TORCH_CHECK)

Original summary for #11204:
Set of math functions that work on both scalars and at::vec::Vectorized,
to be used in #9432.

Original summary for #11205:
Make sure we test the optimized versions of portable kernels even if
they are shadowed by optimized implementations. Intended to support
#9432.

Original summary for #9432:

This is a first cut at #9241 . In this PR I've vectorized a small
initial set of ops: atan2, clamp, fmod_Scalar, maximum, minimum, mul,
pow, and sigmoid. In addition, the following ops should have gotten
vectorized automatically because they already used generic lambdas: add,
div, rsub, sub. I've left covering ops that use the `unary_ufunc_*`
utilities in
[pattern.h](https://github.com/pytorch/executorch/blob/main/kernels/portable/cpu/pattern/pattern.h)
for a follow-up push, because pattern.h and elementwise_util need some
work before we can migrate pattern.h's utilities to be backed by
elementwise_util.

This PR adds an interesting testing problem: in theory, *all* operators
might need test cases long enough to tickle vectorization, because we
might accidentally vectorize ops unexpectedly and break their lambdas
due to anticipated differences in semantics. I address this issue by
using Vectorized for the scalar prologue/epilogue in debug mode (we run
tests in both debug and release) so that we can detect broken lambdas. I
additionally intentionally introduced a bug in the vectorized path in
elementwise_util and manually verified that we saw test failures for
each vectorized op called out above.

Differential Revision: [D76467389](https://our.internmc.facebook.com/intern/diff/D76467389/)

ghstack-source-id: 289985405
Pull Request resolved: #11604

…table_kernels test (#11205)", and "Add vectorization in elementwise_util (#9432)""

Stack was reverted due to internal CI failures. Reapplying as an exported internal diff so that we make sure to catch any more of those.

New fixes:
- straightforward op_sub build fixes
- s/EXPECT_EQ/EXPECT_FLOAT_EQ/ in vectorized_math_test
- define ET_USE_PYTORCH_HEADERS to detect whether exceptions are
  enabled, and use `#if` instead of `#ifdef` to check the macro so
  that we don't use PyTorch headers if exceptions are
  disabled. (otherwise, we might have problems with e.g. TORCH_CHECK)

Original summary for #11204:
Set of math functions that work on both scalars and at::vec::Vectorized,
to be used in #9432.

Original summary for #11205:
Make sure we test the optimized versions of portable kernels even if
they are shadowed by optimized implementations. Intended to support
#9432.

Original summary for #9432:

This is a first cut at #9241 . In this PR I've vectorized a small
initial set of ops: atan2, clamp, fmod_Scalar, maximum, minimum, mul,
pow, and sigmoid. In addition, the following ops should have gotten
vectorized automatically because they already used generic lambdas: add,
div, rsub, sub. I've left covering ops that use the `unary_ufunc_*`
utilities in
[pattern.h](https://github.com/pytorch/executorch/blob/main/kernels/portable/cpu/pattern/pattern.h)
for a follow-up push, because pattern.h and elementwise_util need some
work before we can migrate pattern.h's utilities to be backed by
elementwise_util.

This PR adds an interesting testing problem: in theory, *all* operators
might need test cases long enough to tickle vectorization, because we
might accidentally vectorize ops unexpectedly and break their lambdas
due to anticipated differences in semantics. I address this issue by
using Vectorized for the scalar prologue/epilogue in debug mode (we run
tests in both debug and release) so that we can detect broken lambdas. I
additionally intentionally introduced a bug in the vectorized path in
elementwise_util and manually verified that we saw test failures for
each vectorized op called out above.

Differential Revision: [D76467389](https://our.internmc.facebook.com/intern/diff/D76467389/)

[ghstack-poisoned]

…nels test (#11205)", and "Add vectorization in elementwise_util (#9432)"

Pull Request resolved: #11604

Stack was reverted due to internal CI failures. Reapplying as an exported internal diff so that we make sure to catch any more of those.

New fixes:
- straightforward op_sub build fixes
- s/EXPECT_EQ/EXPECT_FLOAT_EQ/ in vectorized_math_test
- define ET_USE_PYTORCH_HEADERS to detect whether exceptions are
  enabled, and use `#if` instead of `#ifdef` to check the macro so
  that we don't use PyTorch headers if exceptions are
  disabled. (otherwise, we might have problems with e.g. TORCH_CHECK)

Original summary for #11204:
Set of math functions that work on both scalars and at::vec::Vectorized,
to be used in #9432.

Original summary for #11205:
Make sure we test the optimized versions of portable kernels even if
they are shadowed by optimized implementations. Intended to support
#9432.

Original summary for #9432:

This is a first cut at #9241 . In this PR I've vectorized a small
initial set of ops: atan2, clamp, fmod_Scalar, maximum, minimum, mul,
pow, and sigmoid. In addition, the following ops should have gotten
vectorized automatically because they already used generic lambdas: add,
div, rsub, sub. I've left covering ops that use the `unary_ufunc_*`
utilities in
[pattern.h](https://github.com/pytorch/executorch/blob/main/kernels/portable/cpu/pattern/pattern.h)
for a follow-up push, because pattern.h and elementwise_util need some
work before we can migrate pattern.h's utilities to be backed by
elementwise_util.

This PR adds an interesting testing problem: in theory, *all* operators
might need test cases long enough to tickle vectorization, because we
might accidentally vectorize ops unexpectedly and break their lambdas
due to anticipated differences in semantics. I address this issue by
using Vectorized for the scalar prologue/epilogue in debug mode (we run
tests in both debug and release) so that we can detect broken lambdas. I
additionally intentionally introduced a bug in the vectorized path in
elementwise_util and manually verified that we saw test failures for
each vectorized op called out above.

Differential Revision: [D76467389](https://our.internmc.facebook.com/intern/diff/D76467389/)
ghstack-source-id: 289996914

…nels test (#11205)", and "Add vectorization in elementwise_util (#9432)"

Pull Request resolved: #11604

Stack was reverted due to internal CI failures. Reapplying as an exported internal diff so that we make sure to catch any more of those.

New fixes:
- straightforward op_sub build fixes
- s/EXPECT_EQ/EXPECT_FLOAT_EQ/ in vectorized_math_test
- define ET_USE_PYTORCH_HEADERS to detect whether exceptions are
  enabled, and use `#if` instead of `#ifdef` to check the macro so
  that we don't use PyTorch headers if exceptions are
  disabled. (otherwise, we might have problems with e.g. TORCH_CHECK)

Original summary for #11204:
Set of math functions that work on both scalars and at::vec::Vectorized,
to be used in #9432.

Original summary for #11205:
Make sure we test the optimized versions of portable kernels even if
they are shadowed by optimized implementations. Intended to support
#9432.

Original summary for #9432:

This is a first cut at #9241 . In this PR I've vectorized a small
initial set of ops: atan2, clamp, fmod_Scalar, maximum, minimum, mul,
pow, and sigmoid. In addition, the following ops should have gotten
vectorized automatically because they already used generic lambdas: add,
div, rsub, sub. I've left covering ops that use the `unary_ufunc_*`
utilities in
[pattern.h](https://github.com/pytorch/executorch/blob/main/kernels/portable/cpu/pattern/pattern.h)
for a follow-up push, because pattern.h and elementwise_util need some
work before we can migrate pattern.h's utilities to be backed by
elementwise_util.

This PR adds an interesting testing problem: in theory, *all* operators
might need test cases long enough to tickle vectorization, because we
might accidentally vectorize ops unexpectedly and break their lambdas
due to anticipated differences in semantics. I address this issue by
using Vectorized for the scalar prologue/epilogue in debug mode (we run
tests in both debug and release) so that we can detect broken lambdas. I
additionally intentionally introduced a bug in the vectorized path in
elementwise_util and manually verified that we saw test failures for
each vectorized op called out above.
ghstack-source-id: 290334876

Differential Revision: [D76467389](https://our.internmc.facebook.com/intern/diff/D76467389/)

…"Add optimized_portable_kernels test (#11205)", and "Add vectorization in elementwise_util (#9432)""

Stack was reverted due to internal CI failures. Reapplying as an exported internal diff so that we make sure to catch any more of those.

New fixes:
- straightforward op_sub build fixes
- s/EXPECT_EQ/EXPECT_FLOAT_EQ/ in vectorized_math_test
- define ET_USE_PYTORCH_HEADERS to detect whether exceptions are
  enabled, and use `#if` instead of `#ifdef` to check the macro so
  that we don't use PyTorch headers if exceptions are
  disabled. (otherwise, we might have problems with e.g. TORCH_CHECK)

Original summary for #11204:
Set of math functions that work on both scalars and at::vec::Vectorized,
to be used in #9432.

Original summary for #11205:
Make sure we test the optimized versions of portable kernels even if
they are shadowed by optimized implementations. Intended to support
#9432.

Original summary for #9432:

This is a first cut at #9241 . In this PR I've vectorized a small
initial set of ops: atan2, clamp, fmod_Scalar, maximum, minimum, mul,
pow, and sigmoid. In addition, the following ops should have gotten
vectorized automatically because they already used generic lambdas: add,
div, rsub, sub. I've left covering ops that use the `unary_ufunc_*`
utilities in
[pattern.h](https://github.com/pytorch/executorch/blob/main/kernels/portable/cpu/pattern/pattern.h)
for a follow-up push, because pattern.h and elementwise_util need some
work before we can migrate pattern.h's utilities to be backed by
elementwise_util.

This PR adds an interesting testing problem: in theory, *all* operators
might need test cases long enough to tickle vectorization, because we
might accidentally vectorize ops unexpectedly and break their lambdas
due to anticipated differences in semantics. I address this issue by
using Vectorized for the scalar prologue/epilogue in debug mode (we run
tests in both debug and release) so that we can detect broken lambdas. I
additionally intentionally introduced a bug in the vectorized path in
elementwise_util and manually verified that we saw test failures for
each vectorized op called out above.

Differential Revision: [D76467389](https://our.internmc.facebook.com/intern/diff/D76467389/)

[ghstack-poisoned]

…ortable_kernels test (#11205)", and "Add vectorization in elementwise_util (#9432)""

Stack was reverted due to internal CI failures. Reapplying as an exported internal diff so that we make sure to catch any more of those.

New fixes:
- straightforward op_sub build fixes
- s/EXPECT_EQ/EXPECT_FLOAT_EQ/ in vectorized_math_test
- define ET_USE_PYTORCH_HEADERS to detect whether exceptions are
  enabled, and use `#if` instead of `#ifdef` to check the macro so
  that we don't use PyTorch headers if exceptions are
  disabled. (otherwise, we might have problems with e.g. TORCH_CHECK)

Original summary for #11204:
Set of math functions that work on both scalars and at::vec::Vectorized,
to be used in #9432.

Original summary for #11205:
Make sure we test the optimized versions of portable kernels even if
they are shadowed by optimized implementations. Intended to support
#9432.

Original summary for #9432:

This is a first cut at #9241 . In this PR I've vectorized a small
initial set of ops: atan2, clamp, fmod_Scalar, maximum, minimum, mul,
pow, and sigmoid. In addition, the following ops should have gotten
vectorized automatically because they already used generic lambdas: add,
div, rsub, sub. I've left covering ops that use the `unary_ufunc_*`
utilities in
[pattern.h](https://github.com/pytorch/executorch/blob/main/kernels/portable/cpu/pattern/pattern.h)
for a follow-up push, because pattern.h and elementwise_util need some
work before we can migrate pattern.h's utilities to be backed by
elementwise_util.

This PR adds an interesting testing problem: in theory, *all* operators
might need test cases long enough to tickle vectorization, because we
might accidentally vectorize ops unexpectedly and break their lambdas
due to anticipated differences in semantics. I address this issue by
using Vectorized for the scalar prologue/epilogue in debug mode (we run
tests in both debug and release) so that we can detect broken lambdas. I
additionally intentionally introduced a bug in the vectorized path in
elementwise_util and manually verified that we saw test failures for
each vectorized op called out above.

Differential Revision: [D76467389](https://our.internmc.facebook.com/intern/diff/D76467389/)

[ghstack-poisoned]

…nels test (#11205)", and "Add vectorization in elementwise_util (#9432)"

Differential Revision: D76467389

Pull Request resolved: #11604

…ble_kernels test (pytorch#11205)", and "Add vectorization in elementwise_util (pytorch#9432)"

Summary:
Stack was reverted due to internal CI failures. Reapplying as an exported internal diff so that we make sure to catch any more of those.

New fixes:
- straightforward op_sub build fixes
- s/EXPECT_EQ/EXPECT_FLOAT_EQ/ in vectorized_math_test
- define ET_USE_PYTORCH_HEADERS to detect whether exceptions are
  enabled, and use `#if defined(...) && ...` instead of `#ifdef` to check the macro so
  that we don't use PyTorch headers if exceptions are
  disabled. (otherwise, we might have problems with e.g. TORCH_CHECK)

Original summary for pytorch#11204:
Set of math functions that work on both scalars and at::vec::Vectorized,
to be used in pytorch#9432.

Original summary for pytorch#11205:
Make sure we test the optimized versions of portable kernels even if
they are shadowed by optimized implementations. Intended to support
pytorch#9432.

Original summary for pytorch#9432:

This is a first cut at pytorch#9241 . In this PR I've vectorized a small
initial set of ops: atan2, clamp, fmod_Scalar, maximum, minimum, mul,
pow, and sigmoid. In addition, the following ops should have gotten
vectorized automatically because they already used generic lambdas: add,
div, rsub, sub. I've left covering ops that use the `unary_ufunc_*`
utilities in
[pattern.h](https://github.com/pytorch/executorch/blob/main/kernels/portable/cpu/pattern/pattern.h)
for a follow-up push, because pattern.h and elementwise_util need some
work before we can migrate pattern.h's utilities to be backed by
elementwise_util.

This PR adds an interesting testing problem: in theory, *all* operators
might need test cases long enough to tickle vectorization, because we
might accidentally vectorize ops unexpectedly and break their lambdas
due to anticipated differences in semantics. I address this issue by
using Vectorized for the scalar prologue/epilogue in debug mode (we run
tests in both debug and release) so that we can detect broken lambdas. I
additionally intentionally introduced a bug in the vectorized path in
elementwise_util and manually verified that we saw test failures for
each vectorized op called out above.

Differential Revision:
D76467389
***
fix ET_USE_PYTORCH_HEADERS

…kernels test (#11205)", and "Add vectorization in elementwise_util (#9432)"

Stack was reverted (again! I bypassed some broken jobs and it turns
out this re-broke them) due to internal CI failures. Reapplying as an
exported internal diff so that we make sure to catch any more of
those.

New fixes in first reapply:
- straightforward op_sub build fixes
- s/EXPECT_EQ/EXPECT_FLOAT_EQ/ in vectorized_math_test
- define ET_USE_PYTORCH_HEADERS to detect whether exceptions are
  enabled, and use `#if` instead of `#ifdef` to check the macro so
  that we don't use PyTorch headers if exceptions are
  disabled. (otherwise, we might have problems with e.g. TORCH_CHECK)

New fixes in second reapply:
- So far, none; D76843086 and D76857541 fix things up in preparation for this diff. (some rebase conflict fixes though)

Original summary for #11204:
Set of math functions that work on both scalars and at::vec::Vectorized,
to be used in #9432.

Original summary for #11205:
Make sure we test the optimized versions of portable kernels even if
they are shadowed by optimized implementations. Intended to support
#9432.

Original summary for #9432:

This is a first cut at #9241 . In this PR I've vectorized a small
initial set of ops: atan2, clamp, fmod_Scalar, maximum, minimum, mul,
pow, and sigmoid. In addition, the following ops should have gotten
vectorized automatically because they already used generic lambdas: add,
div, rsub, sub. I've left covering ops that use the `unary_ufunc_*`
utilities in
[pattern.h](https://github.com/pytorch/executorch/blob/main/kernels/portable/cpu/pattern/pattern.h)
for a follow-up push, because pattern.h and elementwise_util need some
work before we can migrate pattern.h's utilities to be backed by
elementwise_util.

This PR adds an interesting testing problem: in theory, *all* operators
might need test cases long enough to tickle vectorization, because we
might accidentally vectorize ops unexpectedly and break their lambdas
due to anticipated differences in semantics. I address this issue by
using Vectorized for the scalar prologue/epilogue in debug mode (we run
tests in both debug and release) so that we can detect broken lambdas. I
additionally intentionally introduced a bug in the vectorized path in
elementwise_util and manually verified that we saw test failures for
each vectorized op called out above.

Differential Revision: [D76754826](https://our.internmc.facebook.com/intern/diff/D76754826/)

[ghstack-poisoned]

…kernels test (#11205)", and "Add vectorization in elementwise_util (#9432)"

Stack was reverted (again! I bypassed some broken jobs and it turns
out this re-broke them) due to internal CI failures. Reapplying as an
exported internal diff so that we make sure to catch any more of
those.

New fixes in first reapply:
- straightforward op_sub build fixes
- s/EXPECT_EQ/EXPECT_FLOAT_EQ/ in vectorized_math_test
- define ET_USE_PYTORCH_HEADERS to detect whether exceptions are
  enabled, and use `#if` instead of `#ifdef` to check the macro so
  that we don't use PyTorch headers if exceptions are
  disabled. (otherwise, we might have problems with e.g. TORCH_CHECK)

New fixes in second reapply:
- So far, none; D76843086 and D76857541 fix things up in preparation for this diff. (some rebase conflict fixes though)

Original summary for #11204:
Set of math functions that work on both scalars and at::vec::Vectorized,
to be used in #9432.

Original summary for #11205:
Make sure we test the optimized versions of portable kernels even if
they are shadowed by optimized implementations. Intended to support
#9432.

Original summary for #9432:

This is a first cut at #9241 . In this PR I've vectorized a small
initial set of ops: atan2, clamp, fmod_Scalar, maximum, minimum, mul,
pow, and sigmoid. In addition, the following ops should have gotten
vectorized automatically because they already used generic lambdas: add,
div, rsub, sub. I've left covering ops that use the `unary_ufunc_*`
utilities in
[pattern.h](https://github.com/pytorch/executorch/blob/main/kernels/portable/cpu/pattern/pattern.h)
for a follow-up push, because pattern.h and elementwise_util need some
work before we can migrate pattern.h's utilities to be backed by
elementwise_util.

This PR adds an interesting testing problem: in theory, *all* operators
might need test cases long enough to tickle vectorization, because we
might accidentally vectorize ops unexpectedly and break their lambdas
due to anticipated differences in semantics. I address this issue by
using Vectorized for the scalar prologue/epilogue in debug mode (we run
tests in both debug and release) so that we can detect broken lambdas. I
additionally intentionally introduced a bug in the vectorized path in
elementwise_util and manually verified that we saw test failures for
each vectorized op called out above.

Differential Revision: [D76754826](https://our.internmc.facebook.com/intern/diff/D76754826/)

ghstack-source-id: 291370586
Pull Request resolved: #11802